-
Notifications
You must be signed in to change notification settings - Fork 8.2k
Bluetooth: controller: nRF21540 FEM support for nRF52x and nRF53x Series #31336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bluetooth: controller: nRF21540 FEM support for nRF52x and nRF53x Series #31336
Conversation
589590c to
0e4563f
Compare
|
I agree with @carlescufi the FEM hardware configuration like pins should be in the device tree. We already have bindings for the nRF21540 FEM in the Zephyr. Also the FEM configuration is added to the nrf21540dk_nrf52840 dts file
west build is invoked
|
|
@carlescufi and @KAGA164 This PR is collection of other authors works. I do not have the knowledge or time in the near future to rework, there is already a related issue #30708, if someone wants to work on it, they can use this PR as base and add commits to port to DTS macros. |
|
@auroraslb or @KAGA164 could you please pick this up and rework it accordingly? |
@carlescufi does that mean I should not work on #30708? Just clarifying. |
|
@carlescufi This PR is relatively big in terms of feature support, should be reviewed as-is and merged. The DT porting should be addressed in #30708, which can be done by @mbolivar and I can assist in its review and testing. Hope the functional changes in this PR gets some reviews, else this is now entering the merge conflicts due to other PRs modifying the files common to this PR. |
Sorry for the delay. No, apparently no one is working on that, so you can feel free to pick that up in fact. |
0e4563f to
66caaaf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commit log says the motivation is "so that DPPI 0-4 available for application's use" -- where is that going to be documented?
More generally, PPI values seem like something that should be moved into DT, since they are boot time hardware configuration values. Another benefit would be that users could override this macro with an overlay as they desire.
Would you agree? If so, that also would solve the documentation problem if there is no existing doc, because the pages in the DT bindings index would be the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commit log says the motivation is "so that DPPI 0-4 available for application's use" -- where is that going to be documented?
I thought this would document it:
zephyr/modules/hal_nordic/nrfx/nrfx_glue.h
Line 229 in 45cdc05
| /** @brief Bitmask that defines PPI channels that are reserved for use outside of the nrfx library. */ |
PPI values seem like something that should be moved into DT
Agree.
(Just thinking aloud, PPI/DPPIs and other peripherals are used by controller at scheduled time periods, they can but are not currently been used outside the Zephyr controller. nRF Connect SD controller based application do use outside the controller's scheduled time periods).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgive my ignorance, but are these Kconfig options being copy/pasted from somewhere else for a different SoC?
If not, they should definitely be in DT instead, along with the polarity (since we have the GPIO_ACTIVE_LOW flag in DTS), CSN pin, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not against use of DT, it is just that original controller contribution was before use of DT, and not all of controller has been ported to DT use.
they should definitely be in DT
Agree. As a subsequent PR, please do work on the port.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a copy/paste error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes. Will fix it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, will fix it.
66caaaf to
82a5532
Compare
|
@mbolivar-nordic @anangl @rugeGerritsen @KAGA164 could you please review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK to the best of my limited ability to review. I'll take on conversion of pin Kconfigs to DT as follow up PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... PDN pin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it would be good to mention what's the unit of this value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| #define NRF_GPIO_CSN_PIN ((CONFIG_BT_CTLR_GPIO_PA_PIN) - 32) | |
| #define NRF_GPIO_CSN_PIN ((CONFIG_BT_CTLR_GPIO_CSN_PIN) - 32) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These channels should be added to HAL_USED_PPI_CHANNELS, similarly to how it is done for the PA/LNA ones: https://github.com/zephyrproject-rtos/zephyr/blob/82a55328ccc96abeff252dc63e73b3577973abf0/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio_nrf5_dppi.h#L582-L588
Same applies to the corresponding change in radio_nrf5_ppi.h.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like it should be:
| #define HAL_ENABLE_FEM_PPI 4 | |
| #define HAL_DISABLE_FEM_PPI HAL_ENABLE_PALNA_PPI | |
| #define HAL_ENABLE_FEM_PPI 4 | |
| #define HAL_DISABLE_FEM_PPI HAL_ENABLE_FEM_PPI |
Otherwise, the PDN and CSN pins will be toggled on NRF_TIMER_EVENT_COMPARE3 and NRF_RADIO_EVENT_DISABLED but also on NRF_TIMER_EVENT_COMPARE2 (what would be different from the PPI version) as this event is published to the same channel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, you are right, this would not work. I need to discuss with @bjornspock
The solution was simple reusing existing GPIOTEs, but an additional DPPI... The implementation for PA/LNA will be same as before, when not using FEM then will use GPIOTE OUT Task Toggle mode. With FEM, GPIOTE SET and CLR task will be used for each GPIO PIN, i.e. 1 DPPI for PA or LNA. 1 for PDN+CSN and 1 to CLR all three GPIO on Radio Disable.
82a5532 to
1d21721
Compare
1d21721 to
cb86e59
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anangl please re-review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM now.
Adjust the PPI used by nRF53x so that DPPI 0-4 available for application's use. Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Ported the GPIO PA/LNA support for nRF53x by using a DPPI channel. Fixes zephyrproject-rtos#24142. Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Added correct SOC_NRF5340_CPUNET pin range for BT_CTLR_GPIO_PA_PIN and BT_CTLR_GPIO_LNA_PIN. Signed-off-by: Bjørn Spockeli <[email protected]> Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Added Kconfig options for nRF21540 PDN and CSN pins. Signed-off-by: Bjørn Spockeli <[email protected]> Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Added GPIO control for nRF21540 CSN and PDN lines. Signed-off-by: Bjørn Spockeli <[email protected]> Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Added nRF21540 FEM support for nRF52x Series. Signed-off-by: Bjørn Spockeli <[email protected]> Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
cb86e59 to
440fc6f
Compare
Added nRF21540 FEM support for nRF52x and nRF53x Series.
Thanks to @bjornspock for the FEM contributions and @auroraslb for the DPPI refactoring.
Fixes #24142.
Contains cherry-picked commit from @auroraslb PR: #30732